Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock,comp.os.ms-windows.networking.tcp-ip,comp.answers,news.answers Path: bloom-beacon.mit.edu!hookup!swrinde!ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!aboba From: aboba@netcom.com (Bernard Aboba) Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3 Message-ID: Followup-To: poster Summary: Frequently Asked Questions (and answers) about TCP/IP on PC-Compatible Computers Keywords: TCP/IP, IBM PC, SLIP, PPP, NDIS, ODI Sender: aboba@netcom.com (Bernard Aboba) Reply-To: aboba@netcom.com Organization: MailCom Date: Sun, 24 Jul 1994 20:36:41 GMT Approved: news-answers-request@MIT.Edu Expires: Fri, 2 Sep 1994 00:00:00 GMT Lines: 2581 Xref: bloom-beacon.mit.edu comp.protocols.tcp-ip.ibmpc:17971 comp.protocols.tcp-ip:11697 alt.winsock:11606 comp.os.ms-windows.networking.tcp-ip:2483 comp.answers:6432 news.answers:22977 Archive-name: ibmpc-tcp-ip-faq/part1 comp.protocols.tcp-ip.ibmpc: FAQ Posting, part 1, 8/1/94 ################# Legalese ################# This document is Copyright (C) 1993,1994 by Bernard Aboba, except where the copyright is retained by the original author(s). This document may be distributed non-commercially, provided that it is not modified in any way. However, no part of this publication may be sold or packaged with a product for sale in any form without the prior written permission of Bernard Aboba. This FAQ is presented with no warranties or guarantees of ANY KIND including correctness or fitness for any particular purpose. The author(s) of this document have attempted to verify correctness of the data contained herein; however, slip-ups can and do happen. If you use this data, you do so at your own risk. While we make every effort to keep this FAQ up to date, we cannot guarantee that it is, and we will not be responsible for any damages resulting from the use of the information or software referred to herein. Unless otherwise stated, the views expressed herein are my own. Last time I looked, I had not been appointed official spokesperson of any of the following: The Planet Earth The U.S.Government The State of California (not so good) The University of California, Berkeley The City of Berkeley (bringing you Riot of the Week(SM)) Addison-Wesley Publisher's Group West Any major or minor breakfast cereal (not even oatmeal!) This FAQ will be posted monthly. In between it will be available as: file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip ################# HTML version goes online ################# This FAQ is now fully HTML compatible, and is being automatically converted to HTML. This means that if you have a WWW browser, you can read the FAQ online, and click on links to download individual files. This is how I read the FAQ myself, and it is highly recommended. To get at the HTML version, use: http://www.zilker.net/users/internaut/forth.html#upd ################# Citation entry ################# This FAQ may be cited as: Aboba, Bernard D.(1994) "comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ)" Usenet news.answers, available via file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip, 57 pages. ################# Change History ################# Changes from 7/1/93 posting: FAQ now available in HTML format. Entries changed in last two FAQs sport a *. ################# Related FAQs ################# There is a FAQ available on features of TCP/IP Packages for DOS and Windows. This is available at: file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages. The Windows Sockets Faq is posted to alt.winsock, and is available at: ftp://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ The PC-NFS FAQ is available at: file://seagull.rtd.com/pub/tcpip/pcnfs.FAQ.v1.4.Z or pcnfsfaq.zip file://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ The SNMP FAQ is regularly posted to comp.protocols.snmp The TCP/IP FAQ is posted to comp.protocols.tcp-ip, and is maintained by mailto:gnn@netcom.com. The "How To Get It" FAQ on the Crynwr packet driver collection is irregularly posted to comp.protocols.tcp-ip.ibmpc by Russ Nelson, mailto:nelson@crynwr.com. ################# Book info ################# A bunch of you have requested information on the book I am working on. Here is the basic info: Title: The PC-Internet Connection, TCP/IP Networking for DOS and Windows Authors: Bernard Aboba and Britt Bassett Pages: 800 (estimated), 7" by 9" Distributor: Publisher's Group West ISBN: 1-883979-00-5 Price: $32.95 (est), includes Chameleon Sampler software, WS-Gopher, PC-Eudora. Estimated release: October, 1994 To look at sample chapters from the book, check out the following WWW page: http://www.zilker.net/users/internaut/forth.html For those of in North America who *must* have a look at the book before it comes out, and are willing to comment on it, send me $25 to cover copying and postage, and I'll send you a copy. If you send back comments, I'll return the $25. Since this is a big book, be prepared to spend some time looking at it. For those outside North America, sorry but we're on a tight deadline, and so we will not be able to include you. ################# EXAMPLE CONFIG FILES ################# Many thanks to Dave Fetrow (fetrow@biostat.washington.edu) for creating an archive of setup files. The archive is particularly oriented toward sets of applications that are somewhat tricky, such as combinations involving different driver sets, mixtures of NetWare, TCP/IP, and W4WG, etc. Please include not only the setup and configuration files but some directions. Comments included with the setup files are highly desirable. The files can include your name if you desire. Please mail submissions to ftp@ftp.biostat.washington.edu. The archive itself is located at: ftp://ftp.biostat.washington.edu/ftp/pub/msdos/network.setups Late breaking development: the archive has crashed, and files have been lost. TABLE OF CONTENTS A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? A-2. What are packet drivers? Where do I get them? A-3. What is Winsock? Where can I get it? A-4. What is Trumpet Winsock? How do I get it to dial? A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? A-6. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? For Windows? A-7. What about the software included with various books? A-8. What diagnostic utilities are available to find problems with my connection? Where can I get them? A-9. Is there a CD-ROM with the software included in this FAQ? A-10. Does Windows NT support SLIP? PPP? A-11. Where can I take a peak at the WFW v3.11 VxD beta? A-12. How do I get my BBS to run over TCP/IP? A-13. Are there graphical TCP/IP servers out there? A-14. What methods of dynamic address assignment are available? A-15. How can I set up PPP server on a UNIX host? A-16. What is WinSNMP? B. Questions about drivers B-1. What do I need to know before setting up SLIP or PPP? B-2. How do I configure SLIPDISK? B-3. How do I install packet drivers for Windows applications? B-4. When do I need to install WINPKT? B-5. How to do I run both WinQVT and ODI? B-6. Is it possible to use BOOTP over SLIP? B-7. How do SLIP drivers work? B-8. When do I need to install PKTMUX? B-9. Can NDIS be used underneath multiple protocol stacks of the same type? B-10. Is there an NDIS over packet driver shim? B-11. How do I run NetBIOS over TCP/IP? B-12. How do I run NFS and another TCP/IP application? B-13. How do I run Trumpet Winsock along with KA9Q or NFS? B-14. Sample Stick Diagrams B-15. Strange and wonderful configuration files submitted by readers C. KA9Q Questions C-1. What version of KA9Q should I use and where do I get it? C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation? C-3. How do I configure KA9Q as a SLIP dialup connection? C-4. How do I configure KA9Q as a router? C-5. How do I get KA9Q to support BOOTP? C-6. How do I get KA9Q to support PPP? C-7. How do I get KA9Q to support SLIP dialin? C-8. Can I use KA9Q as a packet filter? D. Hints for particular packages D-1. How do I get DesQView X to run over the network? D-2. Why is NFS so slow compared with FTP? D-3. Where can I get information on running NetWare and TCP/IP concurrently? D-4. What NetWare TCP/IP NLMs are out there and how do I get them to work? D-5. How do I get a telecom package supporting Int 14h redirection to work? D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP? D-7. How do I get Windows For Workgroups to work alongside NetWare? D-9. How come package X doesn't support the AppleTalk packet driver? D-10. NCSA Telnet doesn't reassemble fragments. What should I do? E. Information for developers E-1. What publicly distributable TCP/IP stacks are there that I can use to develop my own applications? E-2. Where can I get a copy of the Windows Sockets FAQ? --------------------- FAQ Begins Here --------------------------- A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? To run TCP/IP on the PC you will need: * Appropriate hardware, such as: Ethernet card Token Ring card AppleTalk card Serial Port Any other network card with a packet driver or NDIS or ODI driver, (such as Arcnet), will also work. If your card supports NetBIOS, this is also acceptable, since you can run a packet-driver-over- NetBIOS shim. * Drivers for your hardware. Your card probably came with one or more of the following drivers: Network Device Interface Specification (NDIS) drivers [spec. by 3Com and Microsoft, used by LAN Manager, Windows for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0, Windows NT uses 3.0, and WFW supports 2.0 and will support 3.0] ODI Drivers [spec. by Novell, abbreviation for Open DataLink Interface] Packet Drivers [spec. by FTP Software] TCP/IP stacks have been written for each of these driver interfaces, so the important thing is whether your chosen stack is compatible with the interface available for your card. A shim is software that runs on top of one set of drivers to provide an interface equivalent to another set. This is useful, for example,if you are looking to run software requiring an NDIS driver(such as Chameleon NFS) alongside software requiring a packet driver interface (such as KA9Q, Gopher, Popmail, NCSA Telnet, etc.), or run software intended for, say, a packet driver over an NDIS driver instead. Shims are available to run packet drivers over NetBIOS, ODI, or NDIS, in order to run software expecting a packet driver over NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). * A TCP/IP protocol stack. The TCP/IP protocol stack runs on top of the driver software, and uses it to access your hardware. If you are running a TCP/IP protocol stack that requires drivers that aren't available for your hardware, you're in trouble. Check into this before purchasing! * If running Windows applications that require it, WINSOCK.DLL. Windows Sockets is a sockets interface which was created as a Windows DLL. Each TCP/IP implementation requires its own version of Windows Sockets. Trumpet Winsock and VxDTCP are the only two publicly distributable Windows Sockets implementations. WINSOCK.DLL provides 16-bit support; WSOCK32.DLL provides 32-bit support. * Applications software. Although most of us in this newsgroup seem to spend our time looking for working combinations of applications,WINSOCK.DLLs, Windows Sockets compliant TCP/IP implementations, shims, drivers, and hardware, ultimately your goal is eventually to run an application successfully. If and when that happens, please send me a note, so I can add it to this FAQ. A-2. What are packet drivers? Where do I get them? Packet drivers provide a software interface that is independent of the interface card you are using, but NOT independent of the particular network technology. As Frances K. Selkirk (fks@vaxeline.ftp.com) notes: "That's one reason they're easier to write than ODI drivers! If you write a class three (802.5 Token Ring) driver, you will need to use software that expects a class three driver, not software that expects a class 1 (DIX ethernet) driver. There are a few drivers that fake class 1. I believe only class 1 and class 6 (SLIP) drivers are supported by freeware packages." The chances are fair that your Ethernet card came with a packet driver, and if so, you should try that first. If not, then you can try one of the drivers from the Crynwr collection (formerly called the Clarkson Drivers). See the Resource listing for info. For 3COM drivers, try ftp ftp.3com.com. For technical information, try info@3com.com. For marketing and product info, try leads@hq.3mail.3com.com.The packet driver specification is available from vax.ftp.com in packet-d.ascii The following vendors have packet drivers with source available for their pocket lan adaptors: D-Link - +1-714-455-1688 Solectek - +1-619-450-1220 Accton - +1-415-266-9800 Compulan - +1-408-922-6888 (soon Kodiak's Noteport - +1-408-441-6900) You can obtain a complete library of packet drivers from many of the Simtel20 mirror sites, including: file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip. A-3. What is Windows Sockets? Where can I get it? The idea for Windows Sockets was born at Fall Interop '91, during a Birds of a Feather session. From the Windows Sockets specification: [courtesy of Mark Towfiq, mailto:towfiq@Microdyne.COM]: The Windows Sockets Specification is intended to provide a single API to which application developers can program and multiple network software vendors can conform. Furthermore, in the context of a particular version of Microsoft Windows, it defines a binary interface (ABI) such that an application written to the Windows Sockets API can work with a conformant protocol implementation from any network software vendor. Windows Sockets will be supported by Windows, Windows for Workgroups, Win32s, and Windows NT. It will also support protocols other than TCP/IP. Under Windows NT, Microsoft will provides Windows Sockets support over TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will include mechanisms for multiple protocol support in Windows Sockets, both 32-bit and 16-bit. Mark Towfiq writes: "Files and information related to the Windows Sockets API are available via ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much faster connection to the Internet, so you are advised to use that). If you do not have FTP access to the Internet, send a message with the word "help" in the body to either mailto:ftpmail@SunSite.UNC.Edu, or mailto:ftpmail@DECWRL.DEC.Com, to obtain information about the FTP to Mail service there." Alternative sources for the Windows Sockets specification include rhino.microsoft.com (an FTP server running NT), as well as the Microsoft forum on CompuServe (go msl). Currently NetManage (NEWT), Distinct, Spry, FTP and Frontier are shipping Winsock TCP/IP stacks, as is Microsoft (Windows NT and TCP/IP for WFW), Beame & Whiteside Software (v1.1 compliant), and Sun PC-NFS. If you are looking for a Winsock.dll, you should first contact your TCP/IP stack vendor. Novell has one in beta for their Lan Workplace for DOS. A-4 What is Trumpet Winsock? How can I get it to dial? Peter Tattam has released a shareware Windows Sockets compliant TCP/IP stack. You can obtain it via file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zipwinapps.zip, or file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip. The first thing to do after you download WINSOCK.ZIP is to create a directory for Trumpet Winsock, such as C:/TRUMPWSK, and put it in your DOS PATH statement. Trumpet Winsock operates over packet drivers, or over a serial port using its own built-in SLIP/CSLIP. If you are using a network adapter, this means that you will have to locate a packet driver for your adapter, and load it. Trumpet Winsock also comes with WINPKT, and this is loaded next, via the command WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver] You will then enter Windows, and create a group in the Program Manager for all the files that come with Trumpet Winsock. The stack itself is loaded by executing TCPMAN. Applications that come with it include WinCHAT, a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie. When you first execute TCPMAN, you will be asked to fill out the setup information for the stack. Select whether you will be using a network adapter or SLIP; you cannot use both. Since Trumpet Winsock does not yet support PPP, you will need to load the EtherPPP driver and WINPKT prior to running Windows. EtherPPP is available via file://merit.edu/pub/ppp/etherppp.zip. This is an Ethernet simulation driver, so you will configure Trumpet Winsock as though it were running over an Ethernet Packet driver, i.e. by loading WINPKT 0x60, and setting the packet driver vector in TCPMAN to 60. EtherPPP comes with its own dialer, so you will need to create a dialing script. If your TCP/IP address will be changing, you will also need to write a little batch script to capture the assigned IP address, and insert it into Trumpet's initialization file. EtherPPP takes up too much RAM (121K), but otherwise works fine. If for some reason you don't like Trumpet Winsock's scripting language, you can use any other comm program that doesn't drop carrier on exit, or the DIALER program, available via: file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip. As for Trumpet Winsock's built-in scripting language, the default dialout script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (mailto:geoff@satro.demon.co.uk): # # initialize modem # output atzm0\13 input 10 OK # # set modem to indicate DCD # output at&d2&c1\13 input 10 OK\n # # send phone number # output atdt0813434848\r # # my other number # #output atdt241644\13 # # now we are connected. # #input 30 CONNECT # # wait till it's safe to send because some modem's hang up # if you transmit during the connection phase # #wait 30 dcd # # now prod the terminal server # #output \13 # # wait for the username prompt # input 30 ogin: username Enter your username output \satro\r # # and the password # input 30 assword: password Enter your password output \my password\r # # we are now logged in # input 30 otocol: # # see who on for informational reasons. # output SLIP\r input 30 HELLO A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? Right now there are a wealth of publicly distributable TCP/IP applications running under DOS. Windows also has a wealth of programs available, including implementations of Gopher, Mail (POP3/SMTP), FSP, Mosaic, Telnet, FTP, IRC, and WAIS. See the Resource listings for information. A-6. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? For Windows? For OS/2? For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. These are packet drivers that can be used along with a dialer. For PPP, I recommend the EtherPPP packet driver described above. There is a special version of NCSA Telnet for PPP, available from ftp://merit.edu/pub/ppp. KA9Q supports SLIP/CSLIP, but unfortunately can not be used as a TCP/IP protocol stack to run other apps. I have heard good things about IBM's TCP/IP for OS/2, but haven't used it msyelf. Please see the FAQ from news:comp.os.os2.networking for details. IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also offer SLIP support in their products. See the resource listings for details. A-7. What about the software included with various books? The software included with various books (including mine) is usually Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but not connection over a network, and includes software for FTP, Telnet, TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock compatible, so you can run any Windows Sockets-compatible application over it. Installation is quite a bit simpler compared with going the Trumpet Winsock route, so this is probably the best way to go assuming that you are a dialup IP user. A-8. What diagnostic utilities are available to find problems with my connection? Where can I get them? Frequently used diagnostic utilities include ifconfig (checks the configuration of the network interfaces), ping (tests IP layer connectivity), traceroute (traces the route that a packet takes between two sites), netstat (checks the routing table), tcpdump (protocol analyzer), arp (looks at the IP to Ethernet address mappings). KA9Q includes ifconfig, ping and traceroute functions. In KA9Q hop check is the equivalent of traceroute. The Trumpet TCP/IP stack also has a hopchk2 command that is a traceroute equivalent. Etherload is very useful for network profiling, while Etherdump can be used for packet catching, although I wish it would give more information, along the lines of TCPDUMP. Trumpet Winsock comes with Windows implementations of Ping and Traceroute. A-9. Is there a CD-ROM with the software included in this FAQ? The Packet Driver, WinSock & TCP/IP CD-ROM is available from CDPublishing for $29.95. This includes the packet drivers of course, but also lots of other DOS and Windows TCP/IP stuff, including Windows Sockets applications. It also includes the text of all the RFCs. This is now somewhat out of date (it was cut in December), but is otherwise highly recommended. CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431, mailto:info@CDPublishing.com, ftp://ftp.CDPublishing.com/, Gopher site: gopher://gopher.CDPublishing.com/, WWW: http://www.CDPublishing.com/ A-10. Does Windows NT support SLIP? PPP? The "Daytona" release of Windows NT will include support for PPP (client and server) and SLIP (client), both including support for Van Jacobson header compression. A-11. Where can I take a peak at the WFW v3.11 VxD beta? This is a beta release of the forthcoming 32 bit-TCP/IP stack for Windows for Workgroups v3.11. This is looking *very* good; it's fast, and has worked fine for me. It also supports a host of very nice new features, including DHCP automatic configuration, WINS name resolution, and Windows Sockets v1.1. However, plesae not that it does not offer SLIP or PPP support. The final beta release is now available via: ftp://ftp.microsoft.com/PerOpSys/WFW/tcpip/ A-12. How do I get my BBS to run over TCP/IP? First off, let's clarify what we mean by "over TCP/IP." Usually this means "accessible via Telnet." Be aware that doing this will not necessarily work well, since few BBSes have been tested running over TCP/IP. As a result you may experience frequent crashes, or abominable transfer rates. For example, I have seen transfer rates as low as 100 characters/second over a 14.4 Kbps PPP connection which routinely supports 1600 cps transfers with FTP. This situation might be improved by running an FTP server instead. This could be accomplished for example by running KA9Q in another window under DesQView, or by putting the files on an NFS-mounted drive, then using another machine as the FTP server. One way to hook up a multi-line BBS is to use a terminal server, and hook up the BBS's serial ports to that. The disadvantage of this is that if your BBS is really big you will need multiple terminal servers which will each have their own domain names and TCP/IP addresses. Confusing. Brian Clements of Murkworks has a better solution, called BBSnet. It provides a Telnet interface that looks like a FOSSIL driver. The first version runs partly as an NLM; some of the code resides on the server. For info, contact BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676, +1 315 265 4717, mailto:info@MurkWorks.com eSoft has also recently announced that they are working on a TCP/IP compatible version of TBBS. Look for this to be shown at OneBBS Con '94 in Atlanta. A-13. Are there graphical servers out there? Yes! For Windows there is a graphical SMTP daemon which is not very functional (it can't do as much as KA9Q); several Web servers, including a Windows version of NCSA's HTTP, and SerWeb. For Windows NT, The European Microsoft Windows Academic Consortium (EMWAC) has released Windows NT servers for Gopher, WAIS, and WWW. These servers are easy to install, and fast, and offer the full complement of capabilities, including support for forms, access to WAIS indices from within HTTPS, installation as a Windows NT service, etc. See the resource section for details. A-14. What methods of address assignment are available? Methods of address assignment include client/server protocols (RARP, BOOTP, DHCP), as well as script-based methods (terminal server indicates, "your address is 192.187.147.2"). PPP supports assignment of addresses from the server. As part 2 of this FAQ discusses, there are RARP and BOOTP clients and servers available for DOS. Typically the clients work by stashing the IP address in a DOS environmental variable. It is then your responsibility to modify the appropriate config files to reflect this address. This can be done using a DOS batch script and a utility such as DOS awk. This same approach can be used to modify config files when using EtherPPP; this does not place the IP address into a variable, but the output of EtherPPP can be piped to a file and the IP address picked off and inserted in the appropriate locations. If this sounds complicated, it is; be warned. Trumpet Winsock supports script-based assignment of addresses. Microsoft supports a DHCP client in WFW TCP/IP, and both client and server in Windows NT. There is also a forthcoming DHCP server for Sun. A-15. How can I set up PPP server on a UNIX host? This is not the appropriate place to address that question, but lots of info on this is available in the comp.protocols.ppp FAQ. A-16. What is WinSNMP? WinSNMP is an API which provides a standard interface to to the Simple Network Management Protocol (SNMP) for network management applications running under Windows. Applications written to WinSNMP can run on any WinSNMP-compatible implementation. Vendors supporting WinSNMP include FTP Software, which supports it in both OnNet 1.1, and PC/TCP 3.0. B. Questions about drivers B-1. What do I need to know before setting up SLIP or PPP? Before setting up your SLIP or PPP connection, you should have available the following information: * The domain name and TCP/IP address of your host. * Whether your TCP/IP address will be assigned statically, dynamically, or from the server. * If from the server, whether you will be using RARP, BOOTP or DHCP. * The domain name and TCP/IP address of your machine (if you are not configuring the address dynamically or via BOOTP) * The domain name and TCP/IP address of the primary and secondary Domain Name Server. * The subnet mask. * The domain name and TCP/IP address of an NNTP server. * Whether your host supports POP, and if so, what version. * Whether the host supports compressed or uncompressed SLIP, or PPP. * The size of the Maximum Receivable Unit (MRU). Do not attempt to connect to your host before you have this information, since it will just waste your time and money, and may cause problems for the network. In particular, do not attempt to initiate a connection using a made up TCP/IP address! It is possible that your made-up address may conflict with an existing address. This is probably the quickest way to get people very angry at you. Static addressing means that your TCP/IP address will always be the same. This makes it easy to configure your setup files. Dynamic addressing means that the host will send you a message containing your TCP/IP address when you log on. This can be problematic if your software doesn't support grabbing the address and inserting it into the setup files. If not, then you may have to edit your setup files every time you log on. Yuck! Chameleon NFS includes a version of SLIP which can handle dynamic addressing. The most recent version of Novell's Lan Workplace for DOS does as well. You can also retrieve your address using RARP, BOOTP or DHCP. RARP is only available to those on the same LAN as the RARP server, since it uses broadcasting. BOOTP clients can access BOOTP servers on other LANs via BOOTP relay. DHCP is a BOOTP extension, which allows complete configuration of a client from info stored on a DHCP server, and in addition supports new concepts such as "address leases". Since DHCP frames are very similar to BOOTP frames, devices supporting BOOTP relay will also support DHCP relay. Of course, for DHCP or BOOTP to work, you will need to set up a DHCP or BOOTP server. DHCP servers are available for UNIX, and Windows NT. PPP also supports server assignment of TCP/IP addresses. B-2. How do I configure SLIPDIAL? From Ashok Aiyar, mailto:ashok@biochemistry.bioc.cwru.edu: PHONE Script Files: PHONE comes with several scripts (for various modems) and for the University of Minnesota Terminal server built into it. The command PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD, which can be edited to your needs (modem and slip server) The documentation that accompanies PHONE, provides good instructions on writing script files to get PHONE to dial SLIP servers other than the University of Minnesota server. For example here is a script that I use to dial a CISCO server at the University that I attend. Background: To start a SLIP connection, I dial our terminal server, and login with a username and password. After doing so, I start a SLIP session with the following command "slip username-slip.dialin.cwru.edu", followed by my password -- again. Here then is the relevant portion of the PHONE.CMD script file - # # CWRU-TS2 SLIP login script by Ashok Aiyar 3/26/93 # Last revised 3/28/93 Procedure Host.CWRU.Login TimeOut 60 'CWRU-TS2 terminal server is not responding' Message "CWRU-TS2 SLIP login script -- Version 1.1" Message 'Waiting for SLIP server to respond' Quiet ON Expect 'Verification' Message 'Request for User Verification Received from CWRU-TS2' Message 'Sending your user name and password' Quiet OFF Expect 'Username:' Send '%u<' Expect 'Password:' Private Send '%p<' Reject 'Access denied' 'Your user name or password was not accepted' TimeOut 30 'SLIP server did not respond to your validation request' Expect 'CWRU-TS2>' Send 'SLIP<' TimeOut 10 'SLIP server did not respond to SLIP command' Expect 'IP hostname or address:' Send '%u-slip.dialin.cwru.edu<' TimeOut 10 'SLIP server did not respond to hostname' Reject 'Bad IP address' 'Incorrect Hostname' Expect 'Password:' Send '%p<' Reject 'Access denied' 'Password not accepted.' TimeOut 10 Expect 'Header Compression will match your system' Message 'Login to CWRU SLIP server successful' Wait 1.0 EndProcedure Host.CWRU.Login # # Procedure Host.CWRU.LogOut # Nothing special needs to be done to logout EndProcedure Host.CWRU.LogOut # # End of Script file # ---------------------------------------------------------------------- How to use packet drivers other than UMSLIP with PHONE? The quick answer -- there is no "clean" way. Below is a batch file hack that I wrote to use PHONE with other packet drivers. In this example, the packet driver is Peter Tattam's CSLIPPER. To use a batch file like this, you must know the parameters with which you plan to use the packet driver -- i.e interrupt vector, baud rate, port address, and IRQ. This batch file requires UMSLIP.COM, CSLIPPER.EXE, and TERMIN.COM to be in the same directory or in your path ... All that the BATCH file does is to let you dial the SLIP connection using PHONE, load the appropriate packet driver, hangup the connection, and unload the driver when you are done ... -- being CWRUSLIP.BAT -- @echo off rem this batch file is an ugly hack of U. of Minn. "SLIP.BAT" rem awaiting a version of C/SLIPPER that can directly interact rem with PHONE rem CWRUSLIP.BAT file is used with PHONE.EXE to start a SLIP rem connection on CWRU-TS2 rem last modified 3/28/93 -- Ashok Aiyar @echo off cls goto start :start if %1. == ?. goto help if %1. == help. goto help if %1. == setup. goto setup if %1. == dial. goto forceD if %1. == hangup. goto forceH if %1. == quit. goto forceH if %1. == HELP. goto help if %1. == SETUP. goto setup if %1. == DIAL. goto forceD if %1. == QUIT. goto forceH goto bogus goto unload :forceH termin 0x60 umslip >nul phone force hangup goto unload :slipper termin 0x60 REM the following line must be changed to reflect the COM port, REM IRQ, baud rate, and software interrupt lh c:\packet\cslipper com1 vec=60 baud=57600 ether goto end :forceD termin 0x60 umslip >nul phone force dial goto slipper :setup termin 0x60 umslip >nul phone setup goto help :unload termin 0x60 goto end :bogus echo %1 is not a valid command. echo Try "cwruslip help" for a list of valid commands echo. :help echo -------------------------------------------------------------- echo Case Western Reserve University SLIP Setup echo using Univ. of Minnesota PHONE echo -------------------------------------------------------------- echo cwruslip setup modem settings, phone number, username etc. echo. echo cwruslip dial DIAL and establish the SLIP connection echo cwruslip quit HANGUP the phone and unload the driver echo cwruslip help this screen echo. :end -- end CWRUSLIP.BAT -- B-3. How do I install packet drivers for Windows applications? How do I install packet drivers for Windows applications? The secret is to load the packet driver, then run Windows. If you are running Trumpet Winsock, you will also have to load WINPKT before running Windows, as follows: winpkt 0x60 If you are running DOS applications within a virtual DOS session under Windows, you should load PKTMUX after your packet driver, as follows: PKTMUX 4 [or however many sessions you want] WIN [load windows] Then within each DOS session, load PKTDRV, the virtual packet driver. If you are running Trumpet Winsock along with other DOS apps in a virtual DOS session, then you will need to load PKTDRV prior to loading Windows, and then load WINPKT on top of it, as follows: PKTMUX 4 PKTDRV 0x62 WINPKT 0x62 PKTDRV 0x60 WIN TCPMAN will then find the virtual packet driver at 0x62. B-4. When do I need to install WINPKT? PKTMUX and WINPKT both accomplish the same thing: allowing you to connect to a DOS packet driver running in real mode from a virtual DOS session under Windows. PKTMUX is useful when you are running more than one TCP/IP stack, and since it takes up more RAM and is slower than WINPKT, you should only use it when you want to run more than one stack at a time. If you are running only one DOS app, or are using Trumpet Winsock, stick with WINPKT. James Harvey (mailto:harvey@iupui.edu) notes: Winpkt is only useful running DOS applications with built-in TCP/IP stacks under Windows, and for some Windows-based stacks (like the Trumpet winsock.dll). When an application registers with a packet driver TSR to receive packets of a specified protocol type, one of the things it hasto pass as a parameter to the packet driver in the call is the address of a routine in the application that the packet driver is to call when it has a packet to pass back to the application. In the case of an application running in 386 enhanced mode in a DOS shell under Windows that is using a packet driver loaded in real mode before Windows was loaded, the packet driver must ensure that Windows has the application in memory when it does the callback, otherwise the callback jumps off into space and your system locks up. Winpkt does a Windows system call to force the app into memory before the callback is done. Erick Engelke (mailto:erick@development.uwaterloo.ca) notes: Windows in enhanced mode uses the protected mode of the 386 CPU to create multiple virtual machines. Winpkt tells Windows to switch to the correct virtual machine before trying to pass up the packet. This reduces the chances of Windows crashing. B-5. How to do I run both WinQVT and ODI? My advice is to use the Windows Sockets version of WinQVT/Net, Trumpet Winsock, and ODIPKT. ODIPKT will allow you to run packet driver software over ODI. You will also need to load WINPKT for Trumpet Winsock. The loading sequence is: LSL [Link support layer] NE2000.COM [or other ODI driver] IPXODI [IPX version supporting ODI] NETX ODIPKT 1 96 WINPKT 0x60 WIN [run windows] Then run Trumpet Winsock, and load WinQVT/Net. B-6. Is it possible to use BOOTP over SLIP? Yes, but it is easier to use dynamic address assignment to get your IP address. This is where the SLIP server outputs your IP address before switching to SLIP. If you need BOOTP, then you should run a BOOTP server on the SLIP server so that it can tell which SLIP connection originated the request. Of course, the BOOTP server will ignore the hardware address of the request originator, but instead will keep track of the SLIP interface the request came in on. See the question on adding BOOTP to KA9Q for info on how to handle this on the PC. Under UNIX, you may have to add BOOTP capability to your slip driver, and rebuild the kernel. (Not recommended for the squimish). B-7. How do SLIP drivers work? Some TCP/IP applications are written to only support Class 1 (Ethernet) packet drivers, but do not support Class 6 (SLIP). For these applications, you need software to make the application think it is dealing with a class 1 interface. This is done by adding fake ethernet headers to incoming SLIP or PPP packets and stripping the headers off outgoing packets. B-8. When do I need to install PKTMUX? PKTMUX is needed to allow you to use more than one TCP/IP stack at the same time. This is useful if you have applications that require different stacks. Note that you do not need PKTMUX to run different protocols, since packet drivers only look at packets in the protocol they're designed to handle, and therefore you can use more than one of these at a time without conflict. You also don't need PKTMUX if all your applications use the same TCP/IP stack. PKTMUX works by looking at outgoing datagrams, and caching information on source and destination ports and addresses. Using this information, PKTMUX tries to sort incoming datagrams by TCP/IP stack. If it can't figure out which stack to send a datagram to (as might be the case if you were running a server application on a well-known port, and had not sent any outgoing packets yet), PKTMUX will send the datagram to all stacks. If all stacks do not complain about the datagram, PKTMUX will throw away the ensuing outgoing ICMP error message, assuming that one of the stacks correctly received the datagram. If all stacks complain, it will send a single ICMP message and throw the rest away. While PKTMUX does its job very well, there are some situations that it cannot handle, such as port conflicts. If two applications open the same TCP port, chaos is inevitable, and there is little that PKTMUX can do to help. B-9. Can NDIS be used underneath multiple protocol stacks of the same type? No. There is no equivalent to PKTMUX for NDIS. B-10. Is there an NDIS over packet driver shim? Joe Doupnik writes: "No. Packet Drivers work by having an application register for a particular packet TYPE, such as 0800 for IP. NDIS works much differently, by offering a peekahead of every packet to applications in turn, a polling operation. The only way NDIS could gracefully sit on a PD would be to run the Packet Driver in all-types mode and let NDIS see all pkts not used by other clients. Needless to say, that's an undesirable situation. The quick solution, costing about US$100 (at least at my place, more at yours) is a second Ethernet board in the client together with a second IP address (most important, please)." B-11. How do I run NetBIOS over TCP/IP? NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002, which defines three types of NetBIOS nodes: * B nodes, which use UDP broadcast packets to distribute datagrams and resolve names. * P nodes, which use point-to-point communications and which require NetBIOS Datagram Distribution (NBDD) and NetBIOS Name Servers (NBNS). P nodes do not listen to or use broadcast services, so they cannot be used alongside B nodes. Unfortunately NBNS, and NBDD servers were not widely implemented, and those that do exist (such as an implementation from Network Telesystems) are not inexpensive. * M nodes, which use both point-to-point and broadcast. B node technology cannot be used on an IP internet without extensions, since UDP broadcast packets are not forwarded through routers. This is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX broadcast packets are forwarded. However, until very recently, M and P node technology was not supported by popular TCP/IP implementations. For example, PC/TCP supports B node technology with extensions such as a broadcast file, host file, or DNS resolution of NetBIOS names. Windows NT and WFW TCP/IP uses an LMHOSTS file for resolving names. According to Chip Sparling of FTP Software: "From what I remember from our discussions of a few years ago, P nodes were only implemented by Ungermann Bass and 3COM (and they required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant), nobody did M nodes (as far as I remember) and PC-LAN, Lantastic and LanManager used B node. Also, if you did a P or M node it wouldn't be compatible with a B node NetBIOS. We decided that we could give the compatibility and functionality (routability) with a B node plus extensions implementation. So, that's what we did." Without implementation of M and P node technology, the only way to run over an IP internet is to to implement B node technology with extensions, as FTP Software does in PC/TCP. According to Chip, "one way to handle large numbers of hosts on multiple networks is to use the broadcast file extenstion. Instead of putting specific ip addresses in the broadcast file, use a subnet broadcast address like nnn.nnn.nnn.255. which will cover an entire subnet." Assuming you don't need any of the extensions to RFC NetBIOS Microsoft created to make NetBIOS work smoothly in a routed environment (available only in their IP stack), you can choose from a wide variety of commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS support; Performance Technologies has a NetBIOS that runs over packet drivers, as does Accton (LANSoft). If any other vendors are reading this, I'd love to have information on how *you* implement NetBIOS over TCP/IP, and whether you'll be supporting WINS, the new P-node technology name resolution service from Microsoft. WINS will be included in the next WFW TCP/IP release, which is currently in beta test and available for download from ftp.microsoft.com. Consult the beta release documentation for more information on this. B-12. How do I run NFS along with another TCP/IP application? The DOS NFS implementation by M. Durkin now supports a built-in packet multiplexer that can handle NFS plus another stack loaded simultaneously. If you need to load more stacks, then you will need to run PKTMUX as well. See the resource section for details. B-13. How do I run Trumpet Winsock along with KA9Q or NFS? The secret is to load WINPKT on top of the PKTDRV virtual packet driver, if you are running PKTMUX. B-14. Sample Stick Diagrams It has been proposed that we begin to collect some diagrams of working combinations of hardware, drivers, shims, stacks, and applications. I'm game, and have made a start below. If you've got some other exotic configuration that works (or if you've tried one of the configurations below and discovered it doesn't work, drop me a line). Running an individual DOS application under Windows NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III | DOS Session | Windows 3.1 | WinPKT | Packet driver or Shim | DOS | Network Adapter DOS Trumpet, NCSA Telnet, and WinQVT/Net over Ethernet under Windows QVT/NET | TRUMPET NCSA telbin | | | | PKTDRV1 PKTDRVn | | | | DOS Session DOS Session Windows Session +-----------+-----------------+ | | | + | WINDOWS 3.1 ............. WINDOWS 3.1 | | | PKTINT(QVT/NET own) | | | PKTDRVx +-------------------------------+ PKTMUX n | Packet Driver or SHIM | DOS | Network Adapter PC Gopher III, NCSA Telnet over CSLIP under Windows PC Gopher III NCSA telbin | | PKTDRV1 PKTDRVn | | DOS Session DOS Session +-----------+-----------------+ | + WINDOWS 3.1 | | | | + PKTMUX n | CSLIPPER | DOS | Serial Port PC Gopher II and NetWare on a LAN - Alternative I [Didn't work for me, but it's supposed to be OK] NetWare PC Gopher | III | | | DOS Session NETX | | Windows 3.1 | | PDIPX WINPKT / \ / \ / \ / \ / Packet Driver | DOS | Network Adapter PC Gopher III and NetWare on a LAN - Alternative II PC-Gopher III | DOS Session | Windows 3.1 | | NetWare | \ / NETX WINPKT \ / IPXODI ODIPKT \ / \ / | Link Support Layer | ODI driver | DOS | Network Adapter WinQVT/Net and PC Gopher II and NetWare over a LAN - Alternative I PC Gopher III | Win QVT/Net PKTDRV1 | | | DOS session Windows 3.1 | | Windows 3.1 PKTINT (QVT/NET own) | | | PKTDRVn WinPKT | | | NetWare +----------------+ | | | | | PKTMUX n NETX | | \ PDIPX \ | \ | \ | \ | Packet Driver --------------+ | DOS | Network Adapter WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II QVT/Net PC Gopher III NCSA telbin | | | | PKTDRV1 ..... PKTDRVn | | | | | DOS Session DOS Session Windows Session +-----------+-----------------+ | | | | | WINDOWS 3.1 .......................WINDOWS 3.1 | | | PKTINT(QVT/NET own) | | | PKTDRVx | | | | | | | | +------------------+------------+ | NetWare | \ / NETX PKTMUX n (use if >1 TCP/IP app) \ / IPXODI ODIPKT \ / \ / | Link Support Layer | ODI driver | Network Adapter PC Eudora and Windows Trumpet over CSLIP under Windows using Trumpet Winsock PC Eudora Windows Trumpet \ / \ / \ / \ / TCPMAN | Windows 3.1 | WINPKT 0x60 | DOS | Serial Port PC Eudora and Windows Trumpet supporting Ethernet and CSLIP under Windows using NDIS supporting stack [Chameleon] [Please note: this is not possible under Trumpet Winsock, since it can only handle a single interface; it requires a stack that routes] PC Eudora Windows Trumpet \ / \ / \ / \ / Chameleon NEWT | Windows v3.1 | +------------------+ | | Protocol Manager | | | NDIS Mac Driver Serial Port | DOS | Ethernet card PC Eudora, Windows Trumpet, and KA9Q under Windows WinTrump PC Eudora \ / \ / KA9Q \ / | | PKTDRV TCPMAN \ | \ / \ / \ / \ / Windows | PKTDRV 0x62 | PKTMUX 2 | Packet Driver | DOS | Ethernet Card HGopher, PC Eudora, and WinTrumpet Under Windows (Whether the TCP/IP stack is loaded before or after Windows depends on the stack) HGopher | | PC | Eudora | WinTrumpet \ | / \ | / \ | / \|/ TCPMAN | Windows 3.1 | WINPKT | Packet Driver | DOS | Ethernet Card B-15. Strange and wonderful configuration files submitted by readers Robert Clift (mailto:clifta@sfu.ca) writes: "I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q (gopher and FTP server), and POPMail all running together under Windows over PKTMUX on a 3C503 packet driver (and Ethernet card)." Here is the stick diagram (yikes!): Win/QVTNet 3.7 KA9Q Gopher PC POPMail 3.2 PC Gopher III 1.01 on interrupt 65 & FTP Server \ / \ | \ / \ | \ / \ | \ / \ PKTDRV PKTDRV \ | / \ DOS Session DOS Session \ | / \ | ------------------- \ | / Windows 3.1 | PKINT | PKTDRV on Int 65 no listeners set | PKTMUX 1.2 with 3 channels | Clarkson 3C503 Packet Driver | DOS | 3Com Etherlink II/16 TP | Ethernet NOTES: Win/QVTNet must be loaded as the very first Windows application and must be kept operating as long as your are in Windows. It appears that its TCP/IP stack does some strange things when it disconnects and kills access to the actual packet driver. I run PC gopher and POPMail alternatively, so they share one channel which is allocated via PKTDRV before running the application and deallocated after the application is finished (I usually throw in a reset command to PMTMUX as well just to be safe). To explain what is happening (as best I can since a lot of this came from experimentation): 1. The packet driver is loaded 2. PKTMUX is run over the packet driver in order to multiplex it (in this case three channels). 3. A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and the packet driver is told that it is not to listen for any server requests. 4. PKINT is loaded over top of the virtual packet driver 5. Start Windows and run Win/QVTNet as the first application, it must be kept running throughout the Windows session. 6. Load a virtual packet driver from a DOS session and start KA9Q. I use the following batch file to do this: c:\network\pktdrv 63 /l h: cd \ net091b c:\network\pktdrv 63 /uu c:\network\pktmux /r 7. Load a virtual packet driver and run PC Gopher or POPMail as needed. I use the following batch files for PC Gopher and POPMail respectively: c:\network\pktdrv 63 h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary c:\network\pktdrv 63 /uu c:\network\pktdrv 66 /c h:\popmail\popmail /noems c:\network\pktdrv 66 /uu 8. The only problem seems to be that the NNTP module in Win/QVTNet will not operate correctly if POPMail is operating. Otheriwse it seems to work okay without too many problems. C. KA9Q Questions C-1. What version of KA9Q should I use and where do I get it? There are so many releases of KA9Q that it is a significant amount of work just to keep track of them all. This has occurred partly because KA9Q does not support extended or expanded memory, and therefore many people have needed to customize it with the features relevant to them in order to allow it to do what they want as well as fit into memory. The primary difference among the various releases is whether they include code for a BBS, packet radio support (AX.25), synchronous cards (for use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS, RIP or PPP support. The three primary KA9Q releases at this time are those managed by Ashok Aiyar (ashok@biochemistry.bioc.cwru.edu), those put out by Demon Internet Services (DIS), and the JNOS distribution. JNOS is the primary packet radio- oriented release; the other two major releases do not include AX.25 support. Since JNOS does not include several features important to non-packet radio users (DNS/Gopher/CSO server, hop check), try one of the other two releases if you're not interested in packet radio. Ashok's release is based on the N1BEE 0.85-beta which in turn is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO, gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet filtering support. Please not that this release does *not* include radio or synchronous card support, unlike the standard KA9Q release, and only support SLIP/CSLIP. Also, there is no DNS server support, and the tip command has been removed, so that you need to use an external dialer to make the connection. Available as: file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.txt, file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.map, file://biochemistry.bioc.cwru.edu/pub/nos/nos192.txt, file://biochemistry.bioc.cwru.edu/pub/nos/nos_1229.man, file://biochemistry.bioc.cwru.edu/pub/nos/vt102.zip, file://biochemistry.bioc.cwru.edu/pub/nos/filter.txt, file://biochemistry.bioc.cwru.edu/pub/nos/autoexec.nos The TextWin version from Demon Internet Services includes support for DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server, VT102 support, NTP, BBS, SLIP/CSLIP,PPP (I don't know anyone who has gotten this to work), demand dial, ping, hop check (traceroute equivalent). From mailto:mike@childsoc.demon.co.uk (Michael Bernardi): "Demon Internet Services have a dialin Internet service in the UK. They also support a customised version of KA9Q optimised for dialup, they also support the PCElm mailer, SNEWS news reader and a customised front end. There is also a combined NEWS and MAIL program called CPPNEWS and an alternative MAIL program called VIEW, these last are unsupported by mailto:Internet@demon.co.uk but other DIS users do support them. All these programs can be found on ftp://ftp.demon.co.uk/pub/ibmpc/ and are written to work with KA9Q (specifically the DIS version)." Anthony McCarthy has added a multi-windowing system to KA9Q that supports the mouse, which has been recommended. See Resource listings for info. The DIS release includes three versions, small, medium and large. The large version includes everything but the kitchen sink, including an NNTP server. I also believe it includes the KA9Q BBS code, and radio support. Editorial: To my mind, the time has come for the major releases to combine their code bases and produce a version with the best features of all of them. To my mind, the ideal KA9Q release would be a release combining the improved server support of the CWRU release with a working PPP implementation, demand dial, and DNS server support. C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation? KA9Q is usually run from a startup script, such as my script startnos.bat: \nos\drivers\8003pkdr \nos\net -d \nos Here I first load the packet drivers for my 8003 Ethernet card, then run KA9Q (known as net.exe). The KA9Q package then reads commands from a configuration file, called AUTOEXEC.NOS in some implementations, AUTOEXEC.NET in others. For VT100 emulation with KA9Q, try using Giles Todd's VT102.COM, available via ftp://ftp.demon.co.uk/pub/ibmpc/DIS. C-3. How do I configure KA9Q as a SLIP dialup connection? Here is a sample CSLIP only configuration file, which was written for Demon Internet Service's version of KA9Q (as are all other KA9Q sample configs in this FAQ): # This config file is for use with the large TextWin # version of KA9Q available from ftp.demon.co.uk # # Set the host name # hostname foobar.com # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and Van Jacobsen Compression (v) and # MTU = 1008 # attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv ifconfig sl0 ipaddress [192.187.134.3] ifconfig sl0 netmask 255.255.255.0 dialer sl0 dialer.sl0 # # # route all packets over sl0 by default (sl0 is the route # to the Internet) # route add default sl0 # # Time To Live is the maximum number of hops a packet # can take before it is thrown away. This command # prevents packets from looping infinitely. # ip ttl 255 # # The Maximum Segment Size is the largest single # transmission that you care to receive. An mss of 216 # will force folks to send you packets of 256 characters # or less (counting the overhead). # tcp mss 1048 # # The Window parameter establishes the maximum number # of bytes that may be outstanding before your system # expects an ack. If window is twice as big as mss, # for example, there will be two active packets on the # channel at any given time. Large values of window # provide improved throughput on full-duplex links, but # are a problem on the air. # Keep mss <= window <= 2*mss if you're on the air. # tcp window 6888 # # This entry will open net.log in the \spool directory # and will record the server activity of your system. If # you don't want a log, comment out this line; if you do, # make sure you have a \spool directory! # log \textwin\spool\net.log # # Each of the servers (services you will provide) must # be turned on before they will be active. The # following entries turn all of them on. To turn any # function off use the command 'stop' after NET gets # fired up, or just comment out the line here. # start ftp ftpopt binary start echo start discard # start telnet start smtp # This machine uses primary and seconary DNS servers # to resolve addresses domain addserver 192.100.81.101 domain addserver 192.100.81.105 # Command indicating presence of IBM AT isat on # smtp gateway 140.174.7.1 # # # THE END dialer.sl0 file: # Configuration section. # configure: init "ATZ\r" dial_cmd "ATDT" ld_code "" number "15108658169" retries 5 # # Execution section. # execute: # # Toggle DTR. # control down wait 2000 control up wait 2000 # # Initialize the modem. # init wait 3000 "OK" # # Dial and wait for connection. # dial wait 45000 "CONNECT" # # Now log in. # wait 60000 "ogin:" wait 1000 send "userID\r" wait 60000 "word:" send "password\r" After executing this setup file, you should hear the modem dial out to your SLIP host. Assuming that the dialing script is correct, it should login and go into SLIP mode. Type RESET at the prompt. This kills any residual processes that may be operating. At this point you should have a functioning connection. You might try to ping your host via the command: PING If this works, you will then see the round trip time to your host, in milliseconds. Other possible diagnostic commands: ASYSTAT Gives statistics on packets received, sent, etc. TRACE 1011 Shows incoming characters RIP TRACE 1 Traces RIP packets HOP CHECK
Traces the route to the designated system. Useful for figuring out routing problems. C-4. How do I configure KA9Q as a router? The KA9Q configuration that follows uses two interfaces, one a PPP interface (pp0), the other an Ethernet interface (lan). Here I am implementing dial on demand, and can also be doing packet filtering, and DNS serving on the same box. Please note the strange interrupt settings (Interrupt 5, port is COM3). One of the nice things about KA9Q is that it is flexible enough to deal with such situations. Here is a sample router configuration file: # This config file is for use with the large TextWin # version of KA9Q available from ftp.demon.co.uk # # Set the host name # hostname gate.foobar.com # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and PPP # attach asy 0x3e8 5 ppp pp0 8092 576 38400 c ifconfig pp0 ipaddress [192.187.147.2] ifconfig pp0 netmask 255.255.255.0 dialer pp0 dialer.ppp demand # ppp pp0 trace 2 ppp pp0 quick ppp pp0 lcp open ppp pp0 ipcp open # # Packet driver installed at software interrupt # number 0x60. # attach packet 0x60 lan 2 1500 ifconfig lan ipaddress [192.187.157.4] ifconfig lan etmask 255.255.255.0 # route add default pp0 # # The local Ethernet has a Class C network address so # route all IP addresses beginning with 192.187.157 to # it. route add 192.187.157/24 lan # # Time To Live is the maximum number of hops a packet # can take before it is thrown away. This command # prevents packets from looping infinitely. # ip ttl 255 # # The Maximum Segment Size is the largest single # transmission that you care to receive. An mss of 216 # will force folks to send you packets of 256 characters # or less (counting the overhead). # tcp mss 576 # # The Window parameter establishes the maximum number # of bytes that may be outstanding before your system # expects an ack. If window is twice as big as mss, # for example, there will be two active packets on the # channel at any given time. Large values of window # provide improved throughput on full-duplex links, but # are a problem on the air. # Keep mss <= window <= 2*mss if you're on the air. # tcp window 6888 # # This entry will open net.log in the \spool directory # and will record the server activity of your system. If # you don't want a log, comment out this line; if you do, # make sure you have a \spool directory! # log \textwin\spool\net.log # # Each of the servers (services you will provide) must # be turned on before they will be active. The # following entries turn all of them on. To turn any # function off use the command 'stop' after NET gets # fired up, or just comment out the line here. # start ftp ftpopt binary start echo start discard start telnet start smtp # This machine will act as a DNS server; # Boot file is c:\textwin\named.boo, configuration # goes in c:\textwin\spool\zones domain startdns # Command indicating presence of IBM AT isat on # smtp gateway 192.187.157.2 # # Use Router Information Protocol (RIP) to inform # the router at 192.187.147.253 about the existence # of the local network. Send RIP packets every 240 # seconds. Only useful for dedicated routers. rip add 192.187.147.253 240 # # THE END dialer.ppp file: # Configuration section. # configure: init "ATZ\r" dial_cmd "ATDT" ld_code "" number "15108658169" retries 5 # # Execution section. # execute: # # Toggle DTR. # control down wait 2000 control up wait 2000 # # Initialize the modem. # init wait 3000 "OK" # # Dial and wait for connection. # dial wait 45000 "CONNECT" # # Now log in. # wait 60000 "ogin:" wait 1000 send "userID\r" wait 60000 "word:" send "password\r" Here is another routing configuration file, using CSLIP and proxy arp: # This config file is for use with the large TextWin # version of KA9Q available from ftp.demon.co.uk # # Set the host name # hostname gate.foobar.com # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and Van Jacobsen Compression (v) and # MTU = 1008 # attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv ifconfig sl0 ipaddress [157.151.0.253] ifconfig sl0 netmask 255.255.255.0 dialer sl0 dialer.sl0 # # # # Packet driver at 0x60; probably an Ethernet card # attach packet 0x60 lan 2 1500 ifconfig lan ipaddress [157.151.64.1] ifconfig lan netmask 255.255.255.0 # # route all packets over sl0 by default (sl0 is the route # to the Internet) # route add default sl0 # # The local Ethernet has a Class C network address so # route all IP addresses beginning with 157.151.64 to it. route add 157.151.64/24 lan # # Use Proxy ARP arp publish 157.151.64.1 ether 00:00:c0:33:f3:13 arp publish 157.151.64.254 ether 00:00:c0:33:f3:13 # # Time To Live is the maximum number of hops a packet # can take before it is thrown away. This command # prevents packets from looping infinitely. # ip ttl 255 # # The Maximum Segment Size is the largest single # transmission that you care to receive. An mss of 216 # will force folks to send you packets of 256 characters # or less (counting the overhead). # tcp mss 576 # # The Window parameter establishes the maximum number # of bytes that may be outstanding before your system # expects an ack. If window is twice as big as mss, # for example, there will be two active packets on the # channel at any given time. Large values of window # provide improved throughput on full-duplex links, but # are a problem on the air. # Keep mss <= window <= 2*mss if you're on the air. # tcp window 6888 # # This entry will open net.log in the \spool directory # and will record the server activity of your system. If # you don't want a log, comment out this line; if you do, # make sure you have a \spool directory! # log \textwin\spool\net.log # # Each of the servers (services you will provide) must # be turned on before they will be active. The # following entries turn all of them on. To turn any # function off use the command 'stop' after NET gets # fired up, or just comment out the line here. # start ftp ftpopt binary start echo start discard # start telnet start smtp # This machine uses primary and seconary DNS servers # to resolve addresses # domain addserver 157.151.0.2 domain addserver 157.151.0.1 smtp gateway 157.151.0.2 # # Command indicating presence of IBM AT isat on # # # # THE END dialer.sl0 file: # Configuration section. # configure: init "ATZ\r" dial_cmd "ATDT" ld_code "" number "15108658169" retries 5 # # Execution section. # execute: # # Toggle DTR. # control down wait 2000 control up wait 2000 # # Initialize the modem. # init wait 3000 "OK" # # Dial and wait for connection. # dial wait 45000 "CONNECT" # # Now log in. # wait 60000 "ogin:" wait 1000 send "userID\r" wait 60000 "word:" send "password\r" C-5 How do I get KA9Q to support BOOTP? The CWRU NOS version has a working BOOTP client and server built-in, and is the best version if you are looking for BOOTP support. [Does Textwin offer full BOOTP support?] If you are using another version of KA9Q that does not support BOOTP, try the following: Steven L. Johnson (mailto:johnson@TIGGER.JVNC.NET) notes: KA9Q does have a bootp client but it is not compiled in by default. It has a bug that truncates the returned ip address to 16 bits which must be corrected before it will work. It also complains about bootp servers that only support RFC 951 bootp without RFC 1084 (or 1048) vendor extensions. Other than that it seems to work for me. To enable the bootp client, add the following line to config.h: #define BOOTP 1 To correct the ip address truncation problem, in bootp.c change: Ip_addr = (int) reply.yiaddr.s_addr; /* yiaddr */ ^^^^^problem at line 188 to: Ip_addr = (int32) reply.yiaddr.s_addr; /* yiaddr */ ^^^^^^^solution And of course, recompile. This worked on the src1229 (1991) version and may work on the most recent version. I did check to make sure that the bug still exists, but I haven't rechecked whether there are additional problems in the new version. C-6. How do I get KA9Q to support PPP? Although I haven't gotten this to work yet, there is hope. The only major version of KA9Q supporting PPP is the TextWin version. Here is a sample ppp configuration file for it: # Set the host name # hostname aboba.slip.netcom.com ip address [192.187.134.3] # # # # Configure COM3 on Interrupt 5, at 38400 bps with # MTU = 1008 # attach asy 0x3e8 5 ppp pp0 8092 1008 38400 dialer pp0 dialer.ppp ifconfig pp0 netmask 255.255.255.252 ppp pp0 trace 2 ppp pp0 quick ppp pp0 lcp open ppp pp0 ipcp open # # # route add default pp0 # route all packets over pp0 by default (pp0 is the route to # the Internet) # # Time To Live is the maximum number of hops a packet can take # before it is thrown away. This command prevents an inadvertent # infinite loop from occuring with packets in the network. # ip ttl 400 # #------------------------------------------------- # # The Maximum Segment Size is the largest single transmission that # you care to receive. An mss of 216 will force folks to send you # packets of 256 characters or less (counting the overhead). # tcp mss 1048 # #------------------------------------------------- # # The Window parameter establishes the maximum number of bytes that # may be outstanding before your system expects an ack. If window is # twice as big as mss, for example, there will be two active packets # on the channel at any given time. Large values of window provide # improved throughput on full-duplex links, but are a problem on the # air. Keep mss <= window <= 2*mss if you're on the air. # # tcp window 6888 # #------------------------------------------------- # # This entry will open net.log in the \spool directory and will # record the server activity of your system. If you don't want a log, # comment out this line; if you do, make sure you have a \spool # directory! # log \spool\net.log # #------------------------------------------------- # # Each of the servers (services you will provide) must be turned # on before they will be active. The following entries turn all # of them on. To turn any function off use the command "stop" after # NET gets fired up, or just comment out the line here. # start ftp start echo start discard #start telnet start smtp # isat on # domain addserver 192.100.81.101 domain addserver 192.100.81.105 smtp gateway 140.174.7.1 # # # Display Name and IP Address # hostname ip address # # THE END In file dialer.ppp: control down wait 1000 control up wait 1000 wait 2000 send "at\r" wait 3000 "OK" send "atdt8659004\r" wait 60000 "login: " send "\r" wait 5000 "word:" wait 1000 send "\r" C-7. How do I get KA9Q to support SLIP dialin? If you are willing to settle for little or no security, there is not much you have to change to allow a KA9Q system to receive calls, as opposed to originating them. These should include: 1. Setting the system to autoanswer, via use of the ATS0=1 command to the modem. 2. Setting up a trace on the router end, to figure out if it's working, via the command: TRACE 1011, where = sl0 for SLIP, or another value such as LAN or ether0 for the Ethernet interface. It's probably a good idea to put a trace on all interfaces until the system is shaken down. Note that without addition of a special dialing script, this setup is completely insecure! C-8. Can I use KA9Q as a packet filter? Yes! Both the TextWin Large and CWRU NOS versions support this. You can filter by incoming or outgoing, TCP or UDP port number, IP address, SYN bit on, etc. D. Hints for particular packages D-1. How do I get DesQView X to run over the network? V1.0 of DesQView X did not include a TCP/IP protocol stack. Surprise! It required a TCP/IP implementation such as Beame & Whiteside, PC-NFS, FTP's PC/TCP, or Novell LWP. They've corrected the situation in subsequent revisions. Contact QuarterDeck for assistance. [pricing and availability, anyone?] D-2. Why is NFS so slow compared with FTP? NFS usually runs over RPC via UDP, rather than utilizing TCP. NFS only acknowledges a write request when the disk completes; there are no sliding windows as in TCP. This makes NFS fairly inefficient. Frances K. Selkirk (fks@vaxeline.ftp.com ) notes: "There are NFS implementations that use TCP. They are only faster over WANs. UDP is faster over most normally functioning LANs. The lockstep paradigm is inherent to NFS, but some implementations provide the ability to violate it - a speed win when the net is reliable, a loss when it is not. Whatever the transport, NFS will have more overhead than TCP, because it is trying to transparently imitate an OS, and has to do a lot of shuffling and translating." D-3. Where can I get information on running NetWare and TCP/IP concurrently? The bit.listserv.novell group regularly posts a FAQ which includes information on concurrent use of TCP/IP and Novell IPX. D-4. What NetWare TCP/IP NLMs are out there and how do I get them to work? A public and known to work reliable TFTP and BOOTP daemon for NetWare OS 3.1x/4.0x and NetWare/IP are available from file://ftp.novell.de/~/pub/netwire/unsupported/server/bootpd.exe. Contact: mailto:dirk@rhein-main.de D-5. How do I get a telecom package supporting Int 14h redirection to work? INT 14 is the BIOS serial port interrupt. "Int 14h redirection" means that Interrupt 14 is redirected to a Telnet connection to a particular host. This is useful because it allows a communications application to readily support telnet. Int 14h support is becoming increasing common, with vendors such as Mustang (QMODEM Pro) and Procomm Plus for networks having included this feature. Aside from commercial stacks (such as FTP's PC/TCP), try the TCPPORT program in WATTCP, available via file://dorm.rutgers.edu/pub/msdos/wattcp/apps.zip. However, I have tried to get this to run with QMODEM Pro and found that I didn't have enough RAM. FTP's PC/TCP includes a program called tnglass that supports Int 14h redirection. D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP? Rumour has it that there is a serial NDIS driver available called NBR11. This is available via ftp://complab.gtri.gatech.edu/pub/lanman/ndis. D-7. How do I get Windows For Workgroups to work alongside NetWare? ODINSUP from Novell is an NDIS over ODI shim. This allows you to run software requiring ODI drivers, as well as software requiring NDIS drivers. Since IPX and TCP/IP are different protocols, you will not need to run PKTMUX. Available via file://ftp.novell.com/netwire/novfiles/client.kit/doswin/files/WSDOS1.EXE. D-9. How come package X doesn't support the AppleTalk packet driver? An AppleTalk driver is available as appletlk.com as part of the Crynwr driver set. NCSA Telnet 2.3.03 and NuPOP support it, but very few other applications do, including Trumpet Winsock. This is because AppleTalk corresponds to packet driver class 5, while most applications only support Class 1 (Ethernet). Vendors with Windows Sockets implementations that support AppleTalk include FTP Software's PC/TCP. WinQVT/Net's built-in TCP/IP stack version is also rumored to be due to support AppleTalk in a future release. D-10. NCSA Telnet doesn't reassemble fragments. What should I do? Yell at the folks at NCSA to fix the problem, and to notify all the people who are using the same TCP/IP code to insert the fix in their software as well. This problem is really common, and very annoying, and affects NCSA Telnet as well as PC Gopher III, and POPmail. One possible workaround is to set the MTU to 576, but this will not always work. The following solution has been provided by Matthew T Kaufman (mailto:matthew@echo.com): How to get rid of the message: "IP: fragmented packet received, frags not supported" (assuming you have a C compiler and source code) by Matthew T Kaufman Many people on the net have complained that NCSA Telnet (among other useful PC TCP/IP programs) doesn't properly handle fragmented IP packets. this problem becomes especially evident if any of your packets are arriving over SLIP connections. I figured that the fastest way to get it to work would be to go ahead and do it myself rather than wait for it to get to the top of the list of desired features. MANY other programs have used the NCSA TCP/IP implementation, so if you maintain a program which does, PLEASE add this fix. I (and MANY OTHERS) are unable to use your software until you do. I posted the basic form of this fix around the beginning of the year, but it didn't seem to make it into several subsequent versions of related software, so I am posting and mailing this once again, in a revised form, with helpful hints at the end. I request only the following in return: This software revision is in the public domain. It may be used anywhere without further permission from the author. Please credit the origin of the fix in your release notes or bug fix document. (I am "Matthew Kaufman, matthew@echo.com") If you are the official maintainer of a software package which you have added this fix to, please send me an email note letting me know that the fix made it in. (So I don't need to worry that, for instance, the next version of NCSA Telnet or WinQVT/Net isn't going to include this) And, please add this fix as soon as possible. So here's my fix: The following are the changes to the NCSA Telnet TCP/IP engine to add support for IP fragment reassembly. I also know how to make telnet compile properly under Borland C without running out of space in DGROUP (see the end of this) if you have any questions, you can reach me at: matthew@echo.com. I am willing to help, within the limits of my schedule. changes follow: file: engine\ip.c (the only file that needs to change) delete the following: >/* >* We cannot handle fragmented IP packets yet, return an error >*/ > > if(p->i.frags &0x20) { /* check for a fragmented packet */ > netposterr(304); > return(1); > } ---------- after the line: > iplen-=hlen; but before the lines: > /* > * check to make sure that the packet is for me. add this: /* check for fragment and handle. note that the &0x20 above is WRONG */ if(p->i.frags) /* NOW check for a fragmented packet - mtk add*/ { ipfraghandle(p,iplen); /* pass in computed iplen to save time */ return(1); } ---------- and then, at the end of that file (ip.c) add this: /* * IP Fragment Reassembly Hack * by Matthew T Kaufman (matthew@echo.com) * 1/1993, 8/1993 */ typedef struct ipb { DLAYER d; IPLAYER i; uint8 data[4104]; /* "Big Enough" */ }FIPKT; #define IPF_CHUNKS 513 /* 4104 / 8 */ #define IPF_BITWORDS 18 /* 513 / 32 round up + 1*/ #define IPF_BUFFERS 7 /* Max # of different fragmented pkts in transit */ typedef struct { FIPKT pkt; unsigned long bits[IPF_BITWORDS]; int lastchunk; unsigned long lasttime; unsigned int iplen; }FPBUF; static FPBUF far Frag[IPF_BUFFERS]; ipfraghandle(IPKT *p, int iplen) { uint16 fraginfo; uint16 foffset; uint16 iden; FPBUF far *buf; int i; fraginfo = intswap(p->i.frags); foffset = fraginfo & (0x1fff); #define morefrags (fraginfo & (0x2000)) iden = intswap(p->i.ident); /* we already KNOW that this IS fragmented */ /* see if we can find any friends who've already arrived... */ buf = (FPBUF *) 0L; for(i=0; ii.ident == Frag[i].pkt.i.ident) { buf = &(Frag[i]); goto foundfriend; } } /* otherwise, we must be the first one here */ { long oldtime = 0x7fffffff; int oldest = 0; for(i=0; ibits[i] = 0L; /* reset */ buf->lastchunk = 0; /* reset */ /* fill in the header with the current header */ movmem(p,&(buf->pkt), sizeof(DLAYER) + sizeof(IPLAYER) ); } foundfriend: ; /* now, deal with this specific fragment... */ /* copy data */ movmem(&(p->x.data),&(buf->pkt.data[8 * foffset]),iplen); /* update rx chunks information */ for(i=foffset; i<= (foffset+(iplen / 8)); i++) { buf->bits[i/32] |= (unsigned long) (1L<<(i % 32)); } if(!morefrags) { /* now we can tell how long the total thing is */ buf->iplen = (8*foffset)+iplen; buf->lastchunk = foffset; /* actually, lastchunk is more than this, but it */ /* IS true that we only need to check through */ /* this foffset value to make sure everything has */ /* arrived -mtk */ } /* now touch the time field, for buffer LRU */ buf->lasttime = clock(); /* check to see if there are fragments missing */ if(buf->lastchunk == 0) { /* we haven't even gotten a fragment with a cleared MORE */ /* FRAGMENTS flag, so we're missing THAT piece, at least */ return 1; } for(i=0; i<= buf->lastchunk; i++) { /* scanning to see if we have everything */ if(0 == ((buf->bits[i/32]) & (unsigned long)(1L<<(i % 32))) ) { return 1; /* still waiting for more */ } } /* otherwise, done waiting... use the packet we've gathered */ /* first clear stuff from fragment buffer: */ buf->lasttime = 0L; /* mark as free to take */ buf->lastchunk = 0; /* need to do this, because we use it as flag */ buf->pkt.i.ident = 0; /* so we don't find this later */ buf->pkt.i.frags = 0; /* in case anybody above us checks */ /* then send it on its way... */ if(!comparen(nnipnum,p->i.ipdest,4)) { /* potential non-match */ if(comparen(nnipnum,junk,4) && p->i.protocol==PROTUDP) return(udpinterpret((UDPKT *)p,iplen)); return(1); /* drop packet */ } /* end if */ switch (buf->pkt.i.protocol) { /* which protocol */ case PROTUDP: return(udpinterpret((UDPKT *)&(buf->pkt),buf->iplen)); case PROTTCP: return(tcpinterpret((TCPKT *)&(buf->pkt),buf->iplen)); case PROTICMP: return(icmpinterpret((ICMPKT *)&(buf->pkt),buf->iplen)); default: netposterr(303); return(1); } } *** helpful hint: if you run out of space in DGROUP, its because your compiler doesn't place each 'far' data object in its own segment. To make things work, you need to make the raw packet buffer be in its own segment. Here's how: in include/pcdefs.h search for: --> unsigned char far raw[17000]; (the 17000 might be some other number... smaller, if someone tried to fix this before) and change to --> unsigned char far raw[17000]={0,0}; /* force into own segment */ E. Information for developers E-1. What publicly distributable TCP/IP stacks are there that I can use to develop my own applications? In writing an application, you can use device drivers provided by particular vendors, or you can opt for an Application Binary Interface (ABI) that supports multiple TCP/IP protocol stacks, such as Winsock. For a given version of Windows, Winsock is an ABI for both Windows 3.x and Windows NT (via the NT Win16 subsystem). Device drivers are included with PC-NFS and Beame & Whiteside's BW-TCP. Free examples of ABIs are the WATTCP API, the NCSA API (public domain), the Trumpet ABI from Peter Tattum, and the NuPOP ABI. All major TCP/IP vendors have by now implemented Windows Sockets. E-2. Where can I get a copy of the Windows Sockets FAQ? A separate developer-oriented FAQ file about Windows Sockets created by Mark Towfiq is available on ftp://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ and ftp://Microdyne.COM/pub/winsock/FAQ An alternative source for the FAQ is ftp.microsoft.com. ------------------------------ END OF PART 1 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1993 The PC-Internet Connection, Publisher's Group West, 1994 mailto:aboba@netcom.com WWW page: http://www.zilker.net/users/internaut/index.html